<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Idiocy',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/10/17.jpg" alt="Rose hips" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion posts for the day:
	</p>
	<blockquote>
		<p>
			I never said there were no good reason for researchers to use a normal distribution.
			I only said there was no good reason to approximate as the normal distribution if the real distribution is known.
			Unnecessary approximations lead to unnecessary data errors.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I meant it as a compliment, but I suppose it depends on context, ha ha.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I&apos;m not saying I necessarily agree with you, but you make a valid point that reduced complexity could be seen as a fair trade-off for reduced accuracy.
			There are a lot of cases in which people go for the answer that is less correct technically, but makes things simpler to work with.
			An example would be the abstraction in programming.
			More abstraction means more work for the computer, but it makes things simpler for the programmer.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I agree that prevention is important, but I think the methods you mention really only work on an individual basis.
			You can make yourself eat well, but you can&apos;t make everyone eat well.
			There must be something we can do to encourage others to fix their own problems as well.
			Otherwise, the number of cases of chronic illness will only continue to climb.
		</p>
	</blockquote>
	<blockquote>
		<p>
			Yeah, it sounds like we do have several similarities.
			I would never bring a child into this awful world though.
			I might find purpose as a parent through adoption or something, but I would never participate in creating another human being.
			Maybe you have more hope for your offspring than I ever could.
		</p>
		<p>
			The weight loss continues.
			A couple days ago, I lost a ring at work and never could find it.
			I knew my fingers were shrinking, but I didn&apos;t want to replace my rings until I&apos;d finished losing weight so I wouldn&apos;t have to replace them twice.
			Anyway, I got my finger resized after work that day.
			I&apos;ve lost two full ring sizes!
			The lost ring only cost me about ten dollars, too, so it wasn&apos;t a huge loss.
			The design wasn&apos;t particularly great, it was just one of the few rings offered in my size at the time I got it.
			Looking at my options now, I have so many more choices!
			I think I&apos;ll lose another half to a whole ring size before this is over, so that&apos;ll improve my options as well.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I agree, having a support system can do a lot of good.
			If I&apos;d ever had one, perhaps my obesity wouldn&apos;t&apos;ve gotten as bad as it did.
			I&apos;ve got no one though but myself.
			Having to lift myself up without help hasn&apos;t been easy, I&apos;ll tell you that much, but at least I&apos;m on the road to recovery now.
			I&apos;m not sure how much longer it&apos;ll take, but as long as I continue to improve, I&apos;ve got to get to a reasonable state eventually.
			My lack of a support system is very likely a key factor in my perpetual pessimism.
		</p>
	</blockquote>
	<p>
		The idiocy of the school&apos;s refusal to let me register for the courses I need dawned on me today in the context of the coming term and the degree switch.
		I won&apos;t be able to register for any of the courses I need!
		Oddly, this realisation came before I read an email telling me that course registration had opened.
		But anyway ... yeah.
		I&apos;ll need to contact my advisor about the issue and see what they say.
	</p>
</section>
<section id="include.d">
	<h2><code>include.d</code></h2>
	<p>
		After almost a week of thinking about what to do with that messy function in <code>include.d</code>, I&apos;ve decised to remove it entirely.
		It&apos;s $a[API] is just too messy.
		At a minimum, the $a[API] would need to be completely rewritten, but rewriting the $a[API] would break compatibility just as much as removing it altogether.
		And with just how obscure the function&apos;s purpose is (it parses a hidden service block and attempts to create a listing of its port forwards based on a bizarre comment syntax I set up), there&apos;s not likely anyone using it.
		I mean, there&apos;s not likely anyone besides me using <code>include.d</code> at all, but in particular, that function is just too specific to see any real use.
	</p>
	<p>
		When I say the $a[API] is horrid, I mean really mean it.
		As input, is has to take the file location of a <code>torrc</code> file.
		That means it can&apos;t operate on data you have in memory, but must instead operate on data from disk.
		Additionally, <code>torrc</code> files are required by $a[Tor] to have certain file permissions set, or $a[Tor] itself won&apos;t run.
		This means you need to either call this function in a script that you run with elevated permissions or you need to copy your <code>torrc</code> file to an insecure location.
		There&apos;s no good reason for that.
		And finally, even though you need to tell this function the directory of the hidden service&apos;s files, as it uses that directory path to locate the correct hidden service block in the <code>torrc</code> file, it doesn&apos;t use this information to read the files in that directory to find the hidden service&apos;s onion address.
		Instead, you must provide the onion address yourself as well.
		This terrible design decision is an artefact of the fact that I was in fact running it on a copy of my <code>torrc</code>, not running with elevated permissions, so reading the file directly was never an option on my particular setup.
		In short, the $a[API] makes terrible assumptions based on the configuration I was using at the time I built the function.
		It&apos;s not general enough, and it&apos;s not fixable without breaking compatibility with whatever scripts use it, which is probably none.
	</p>
</section>
END
);
